• feat(gotter)!: add DT_HASH fallback, relocation type guard, and hook_symbol #2297 : 2 dependent PRs (#2268 , #2312 )
• refactor(got-patching): extract shared GOT-patching primitives into libdd-got-hook #2282 👈 (View in Graphite)
• main

This stack of pull requests is managed by Graphite. Learn more about stacking.

🎯 Code Coverage (details)
• Patch Coverage: 88.34%
• Overall Coverage: 74.99% (-0.20%)

Artifact Size Benchmark Report

Benchmarks

Comparison

Benchmark execution time: 2026-08-04 13:56:13

Comparing candidate commit 5509c44 in PR branch gyuheon0h/extract-got-hook-crate with baseline commit 38a1987 in branch main.

Found 24 performance improvements and 18 performance regressions! Performance is the same for 98 metrics, 0 unstable metrics.

---------------------------------(------|---^--------)-------------------------------->
                              -0.6%    0%  0.3%     +1.2%
                                 |          |        |
         lower bound of the CI --'          |        |
sample mean (center of the CI) -------------'        |
         upper bound of the CI ----------------------'

----------------------------------------|---------|---(---------^---------)---------->
                                       0%        1%  1.3%      2.2%      3.1%
                                                  |   |         |         |
       significant impact threshold --------------'   |         |         |
                      lower bound of CI --------------'         |         |
       sample mean (center of the CI) --------------------------'         |
                      upper bound of CI ----------------------------------'

scenario:msgpack_decoder::v05/low_sharing/10000

• 🟥 execution_time [+768.581µs; +773.948µs] or [+4.464%; +4.495%]
• 🟥 throughput [-24984.886op/s; -24809.890op/s] or [-4.302%; -4.272%]

scenario:msgpack_decoder::v05/low_sharing/200

• 🟥 execution_time [+15.978µs; +16.208µs] or [+4.593%; +4.659%]
• 🟥 throughput [-25598.765op/s; -25234.547op/s] or [-4.453%; -4.390%]

scenario:msgpack_decoder::v05/low_sharing/2000

• 🟥 execution_time [+169.902µs; +171.041µs] or [+4.920%; +4.953%]
• 🟥 throughput [-27340.573op/s; -27155.575op/s] or [-4.721%; -4.689%]

scenario:normalization/normalize_name/normalize_name/Too-Long-.Too-Long-.Too-Long-.Too-Long-.Too-Long-.Too-Lo...

• 🟩 execution_time [-19.875µs; -19.722µs] or [-9.648%; -9.575%]
• 🟩 throughput [+514331.800op/s; +518089.758op/s] or [+10.594%; +10.672%]

scenario:normalization/normalize_name/normalize_name/bad-name

• 🟩 execution_time [-1.950µs; -1.854µs] or [-10.119%; -9.621%]
• 🟩 throughput [+5538251.401op/s; +5796514.310op/s] or [+10.669%; +11.167%]

scenario:normalization/normalize_name/normalize_name/good

• 🟩 execution_time [-1.672µs; -1.651µs] or [-14.176%; -13.998%]
• 🟩 throughput [+13819644.831op/s; +13985450.942op/s] or [+16.297%; +16.493%]

scenario:normalization/normalize_service/normalize_service/A0000000000000000000000000000000000000000000000000...

• 🟩 execution_time [-36.203µs; -35.971µs] or [-6.768%; -6.725%]
• 🟩 throughput [+134801.777op/s; +135686.713op/s] or [+7.211%; +7.258%]

scenario:normalization/normalize_service/normalize_service/Test Conversion 0f Weird !@#$%^&**() Characters

• 🟩 execution_time [-19.477µs; -19.359µs] or [-10.252%; -10.190%]
• 🟩 throughput [+597503.882op/s; +600952.927op/s] or [+11.352%; +11.417%]

scenario:normalization/normalize_service/normalize_service/test_ASCII

• 🟥 execution_time [+2.809µs; +2.872µs] or [+6.165%; +6.303%]
• 🟥 throughput [-1302595.739op/s; -1273643.189op/s] or [-5.935%; -5.803%]

scenario:profiles_dictionary/profile_string_inserts/threads/1

• 🟥 execution_time [+13.457µs; +18.337µs] or [+4.443%; +6.055%]
• 🟥 throughput [-192993.453op/s; -143454.299op/s] or [-5.708%; -4.243%]

scenario:vec_map/as_deduped_map/already_deduped/16

• 🟥 execution_time [+9.250ns; +9.283ns] or [+38.354%; +38.490%]

scenario:vec_map/as_deduped_map/already_deduped/8

• 🟥 execution_time [+1.202ns; +1.237ns] or [+8.306%; +8.545%]

scenario:vec_map/contains_key/128

• 🟩 execution_time [-716.111ns; -708.912ns] or [-4.571%; -4.525%]
• 🟩 throughput [+387238.719op/s; +391195.524op/s] or [+4.740%; +4.788%]

scenario:vec_map/contains_key/16

• 🟩 execution_time [-30.959ns; -30.669ns] or [-11.807%; -11.696%]
• 🟩 throughput [+8085875.063op/s; +8166259.093op/s] or [+13.251%; +13.383%]

scenario:vec_map/contains_key/64

• 🟩 execution_time [-246.051ns; -243.348ns] or [-5.876%; -5.811%]
• 🟩 throughput [+943208.409op/s; +953997.550op/s] or [+6.171%; +6.242%]

scenario:vec_map/contains_key/8

• 🟩 execution_time [-12.951ns; -12.624ns] or [-15.561%; -15.168%]
• 🟩 throughput [+17226795.033op/s; +17666114.711op/s] or [+17.920%; +18.377%]

scenario:vec_map/get_hit/128

• 🟥 execution_time [+1.141µs; +1.149µs] or [+9.123%; +9.188%]
• 🟥 throughput [-861054.899op/s; -855091.033op/s] or [-8.416%; -8.358%]

scenario:vec_map/get_hit/16

• 🟩 execution_time [-12.382ns; -12.193ns] or [-5.834%; -5.745%]
• 🟩 throughput [+4597891.967op/s; +4667131.562op/s] or [+6.099%; +6.191%]

scenario:vec_map/get_hit/64

• 🟥 execution_time [+238.394ns; +242.468ns] or [+7.064%; +7.185%]
• 🟥 throughput [-1271686.828op/s; -1250896.401op/s] or [-6.705%; -6.596%]

scenario:vec_map/get_hit/8

• 🟩 execution_time [-7.688ns; -7.525ns] or [-12.493%; -12.227%]
• 🟩 throughput [+18149519.963op/s; +18494292.364op/s] or [+13.961%; +14.226%]

scenario:vec_map/get_miss/128

• 🟥 execution_time [+5.104ns; +5.208ns] or [+6.665%; +6.801%]

scenario:vec_map/get_miss/16

• 🟩 execution_time [-18.683ns; -18.448ns] or [-68.249%; -67.391%]

scenario:vec_map/get_miss/64

• 🟥 execution_time [+5.450ns; +5.551ns] or [+10.696%; +10.894%]

scenario:vec_map/get_miss/8

• 🟩 execution_time [-12.930ns; -12.754ns] or [-71.495%; -70.525%]

Benchmark execution time: 2026-08-04 14:05:17

Comparing candidate commit 5509c44 in PR branch gyuheon0h/extract-got-hook-crate with baseline commit 38a1987 in branch main.

Found 19 performance improvements and 26 performance regressions! Performance is the same for 123 metrics, 10 unstable metrics.

---------------------------------(------|---^--------)-------------------------------->
                              -0.6%    0%  0.3%     +1.2%
                                 |          |        |
         lower bound of the CI --'          |        |
sample mean (center of the CI) -------------'        |
         upper bound of the CI ----------------------'

----------------------------------------|---------|---(---------^---------)---------->
                                       0%        1%  1.3%      2.2%      3.1%
                                                  |   |         |         |
       significant impact threshold --------------'   |         |         |
                      lower bound of CI --------------'         |         |
       sample mean (center of the CI) --------------------------'         |
                      upper bound of CI ----------------------------------'

scenario:alloc_free/system/16

• 🟩 execution_time [-1.418ns; -1.375ns] or [-9.043%; -8.773%]

scenario:alloc_free/system/256

• 🟩 execution_time [-1.357ns; -1.318ns] or [-8.680%; -8.430%]

scenario:alloc_free/system/4096

• 🟥 execution_time [+11.379ns; +11.529ns] or [+12.035%; +12.193%]

scenario:alloc_free/system/64

• 🟩 execution_time [-1.397ns; -1.354ns] or [-8.880%; -8.607%]

scenario:credit_card/is_card_number/ 3782-8224-6310-005

• 🟥 execution_time [+3.547µs; +3.744µs] or [+4.589%; +4.844%]
• 🟥 throughput [-599828.322op/s; -567232.861op/s] or [-4.636%; -4.384%]

scenario:credit_card/is_card_number/ 378282246310005

• 🟥 execution_time [+6.074µs; +6.171µs] or [+8.971%; +9.114%]
• 🟥 throughput [-1233545.922op/s; -1215442.586op/s] or [-8.352%; -8.230%]

scenario:credit_card/is_card_number/378282246310005

• 🟥 execution_time [+5.940µs; +6.020µs] or [+9.176%; +9.300%]
• 🟥 throughput [-1314292.376op/s; -1298066.641op/s] or [-8.508%; -8.403%]

scenario:credit_card/is_card_number/37828224631000521389798

• 🟥 execution_time [+8.140µs; +8.175µs] or [+18.082%; +18.159%]
• 🟥 throughput [-3415188.528op/s; -3400351.552op/s] or [-15.374%; -15.308%]

scenario:credit_card/is_card_number/x371413321323331

• 🟥 execution_time [+742.778ns; +745.477ns] or [+13.017%; +13.064%]
• 🟥 throughput [-20252026.743op/s; -20179054.399op/s] or [-11.557%; -11.515%]

scenario:credit_card/is_card_number_no_luhn/ 3782-8224-6310-005

• 🟥 execution_time [+4.204µs; +4.369µs] or [+6.902%; +7.173%]
• 🟥 throughput [-1102738.911op/s; -1058892.461op/s] or [-6.716%; -6.449%]

scenario:credit_card/is_card_number_no_luhn/ 378282246310005

• 🟥 execution_time [+4.665µs; +4.713µs] or [+8.677%; +8.766%]
• 🟥 throughput [-1499486.178op/s; -1484352.634op/s] or [-8.062%; -7.981%]

scenario:credit_card/is_card_number_no_luhn/378282246310005

• 🟥 execution_time [+5.187µs; +5.241µs] or [+10.305%; +10.411%]
• 🟥 throughput [-1873266.801op/s; -1855430.082op/s] or [-9.430%; -9.340%]

scenario:credit_card/is_card_number_no_luhn/37828224631000521389798

• 🟥 execution_time [+8.006µs; +8.049µs] or [+17.790%; +17.886%]
• 🟥 throughput [-3372132.950op/s; -3355031.863op/s] or [-15.176%; -15.099%]

scenario:credit_card/is_card_number_no_luhn/x371413321323331

• 🟥 execution_time [+743.505ns; +746.272ns] or [+13.029%; +13.078%]
• 🟥 throughput [-20270830.337op/s; -20198008.556op/s] or [-11.567%; -11.526%]

scenario:datadog_sample_span/name_pattern_rule_not_matching/wall_time

• 🟥 execution_time [+33.417ns; +33.596ns] or [+21.172%; +21.286%]

scenario:ddsketch_read/ordered_bins/clustered_near_zero

• 🟩 execution_time [-234.921ns; -232.079ns] or [-4.158%; -4.107%]

scenario:ddsketch_read/ordered_bins/collapsing

• 🟩 execution_time [-1.968µs; -1.957µs] or [-7.559%; -7.518%]

scenario:ddsketch_read/ordered_bins/mixed

• 🟩 execution_time [-870.357ns; -863.164ns] or [-7.584%; -7.521%]

scenario:glob_matcher/ascii_case_insensitive_match/wall_time

• 🟩 execution_time [-2.093ns; -2.078ns] or [-7.068%; -7.016%]

scenario:glob_matcher/ascii_exact_match/wall_time

• 🟩 execution_time [-2.086ns; -2.061ns] or [-7.044%; -6.962%]

scenario:glob_matcher/ascii_exact_miss/wall_time

• 🟩 execution_time [-2.420ns; -2.366ns] or [-16.281%; -15.921%]

scenario:no_profiler/short_circuit/16

• 🟩 execution_time [-16.471ns; -16.436ns] or [-39.003%; -38.920%]

scenario:no_profiler/short_circuit/256

• 🟩 execution_time [-16.505ns; -16.471ns] or [-39.084%; -39.005%]

scenario:no_profiler/short_circuit/4096

• 🟩 execution_time [-11.662ns; -11.487ns] or [-10.294%; -10.141%]

scenario:no_profiler/short_circuit/64

• 🟩 execution_time [-16.462ns; -16.432ns] or [-38.996%; -38.923%]

scenario:no_profiler/short_circuit/65536

• 🟩 execution_time [-10.443ns; -10.314ns] or [-9.462%; -9.345%]

scenario:profiler_attached/slow_path_system/16

• 🟩 execution_time [-15.813ns; -15.747ns] or [-14.914%; -14.851%]

scenario:profiler_attached/slow_path_system/256

• 🟩 execution_time [-18.679ns; -18.627ns] or [-17.167%; -17.119%]

scenario:profiler_attached/slow_path_system/4096

• 🟩 execution_time [-20.853ns; -20.698ns] or [-11.895%; -11.807%]

scenario:profiler_attached/slow_path_system/64

• 🟩 execution_time [-16.578ns; -16.398ns] or [-15.535%; -15.366%]

scenario:profiler_attached/slow_path_system/65536

• 🟩 execution_time [-20.784ns; -20.659ns] or [-11.730%; -11.659%]

scenario:redis/obfuscate_redis_string

• 🟥 execution_time [+2.605µs; +3.080µs] or [+8.070%; +9.540%]

scenario:sql/obfuscate_sql_string

• 🟥 execution_time [+22.327µs; +22.583µs] or [+7.867%; +7.957%]

scenario:trace_buffer/4_senders/no_delay

• 🟥 execution_time [+166.489µs; +195.027µs] or [+7.140%; +8.364%]
• 🟥 throughput [-121663.307op/s; -103366.968op/s] or [-7.869%; -6.686%]

Candidate

Omitted due to size.

Baseline

Omitted due to size.

Hey @gyuheon0h cool - this is a good idea! We don't want to end up maintaining N variants of this sort of thing.
Happy to review this but it will have to wait til next week; i'll regress it against all my stuff just to be extra sure before we merge and this week is hectic. For the new hashing modes, you'll want to make sure you test against real binaries linked in this fashion.

Nice - I wanted to do this! Will review first thing Monday 💪 Please don't merge beforehand as I'd like to double check all the allocation profiling stuff that rests on it.

@yannham @scottgerring Ill just stack another PR on top of this with the new changes, so that this PR strictly only focuses on the initial "no new feature" refactor 👍

📚 Documentation Check Results

⚠️ 234 documentation warning(s) found

📦 libdd-gotter - 6 warning(s)

📦 libdd-profiling-heap-gotter - 55 warning(s)

📦 tools - 173 warning(s)

Updated: 2026-08-04 13:20:34 UTC | Commit: 4e8b29b | missing-docs job results

🔒 Cargo Deny Results

⚠️ 3 issue(s) found, showing only errors (advisories, bans, sources)

📦 libdd-gotter - ✅ No issues

📦 libdd-profiling-heap-gotter - ✅ No issues

📦 tools - 3 error(s)

error[vulnerability]: Quadratic run time when checking a start tag for duplicate attribute names
   ┌─ /home/runner/work/libdatadog/libdatadog/Cargo.lock:72:1
   │
72 │ quick-xml 0.37.5 registry+https://github.com/rust-lang/crates.io-index
   │ ━━━━━━━━━━━━━━━━━━━━━━━━━━━━━━━━━━━━━━━━━━━━━━━━━━━━━━━━━━━━━━━━━━━━━━ security vulnerability detected
   │
   ├ ID: RUSTSEC-2026-0194
   ├ Advisory: https://rustsec.org/advisories/RUSTSEC-2026-0194
   ├ `BytesStart::attributes()` returns an `Attributes` iterator which, by default
     (`with_checks(true)`), rejects a start tag that repeats an attribute name. For
     each attribute yielded, the iterator compared the new name against every name
     seen so far in the same tag using a linear scan, so a start tag with `N`
     distinct attribute names cost `O(N²)` byte comparisons. There was no bound on
     `N` other than the size of the buffered start tag.
     
     ## Impact
     
     Any code that parses untrusted XML and iterates a start tag's attributes with
     the default duplicate check enabled can be made to spend CPU time quadratic in
     the number of attributes on a single tag. Because the check is pure computation
     with no `.await`/I/O, an I/O-based timeout on the consumer (for example a read
     or request timeout) cannot interrupt it while it runs.
     
     Measured cost of a single start tag, release build:
     
     | Attributes on one tag | Time |
     |---|---|
     | 80,000  | ~6 s   |
     | 800,000 | ~10 min |
     
     The cost grows with the square of the attribute count, so a start tag of a few
     tens of megabytes can stall a parsing thread for hours. No memory is exhausted
     and the parser does not crash; the effect is CPU exhaustion on the thread doing
     the parsing: a single crafted start tag can pin a CPU core for minutes to hours,
     denying service to that worker. A deployment that places a wall-clock bound on
     parsing, or confines it to a non-critical thread, may consider the availability
     impact lower.
     
     ## Affected code paths
     
     * `BytesStart::attributes()` / `Attributes` iterated with checks enabled (the
       default), and `BytesStart::try_get_attribute`.
     * `NsReader`, which resolves namespaces by iterating a tag's attributes and so
       reaches the same check internally.
     
     Consumers that iterate attributes with `.attributes().with_checks(false)` and do
     not use `NsReader` are not affected.
     
     This was reported as reachable by a remote, unauthenticated attacker in a
     real-world RPKI relying party (NLnet Labs Routinator) via a crafted RRDP
     `snapshot.xml`.
     
     ## Remediation
     
     Upgrade to `quick-xml >= 0.41.0`, where the duplicate check keeps the linear
     scan for start tags with a small number of attributes and switches to an `O(1)`
     hash pre-filter above a threshold, making the whole tag `O(N)`. The reported
     `AttrError::Duplicated` positions are unchanged.
     
     If upgrading is not possible and duplicate-name detection is not required,
     disable it with `.attributes().with_checks(false)` (this does not help
     `NsReader` consumers, which have no equivalent opt-out before 0.41.0).
   ├ Announcement: https://github.com/tafia/quick-xml/issues/969
   ├ Solution: Upgrade to >=0.41.0 (try `cargo update -p quick-xml`)
   ├ quick-xml v0.37.5
     └── tools v38.0.0

error[vulnerability]: Unbounded namespace-declaration allocation in `NsReader` enables memory-exhaustion denial of service
   ┌─ /home/runner/work/libdatadog/libdatadog/Cargo.lock:72:1
   │
72 │ quick-xml 0.37.5 registry+https://github.com/rust-lang/crates.io-index
   │ ━━━━━━━━━━━━━━━━━━━━━━━━━━━━━━━━━━━━━━━━━━━━━━━━━━━━━━━━━━━━━━━━━━━━━━ security vulnerability detected
   │
   ├ ID: RUSTSEC-2026-0195
   ├ Advisory: https://rustsec.org/advisories/RUSTSEC-2026-0195
   ├ `NsReader` resolves namespaces by calling `NamespaceResolver::push` for every
     `Start`/`Empty` event *before* the event is returned to the caller. `push`
     iterated all `xmlns` / `xmlns:*` attributes on the start tag and, for each one,
     appended the prefix bytes to an internal buffer and pushed a `NamespaceBinding`
     (32 bytes on 64-bit) to an internal `Vec`, with no upper bound on the number of
     declarations.
     
     ## Impact
     
     A start tag with `N` namespace declarations drove roughly `3×` the tag's byte
     size in `NamespaceResolver` heap, allocated *inside* `quick-xml` before the
     `NsReader` consumer ever received the event and could inspect or reject it. A
     consumer that bounds its *input* size therefore still cannot bound this
     allocation: an `M`-byte start tag yields on the order of `3 × M` bytes of
     resolver heap the caller never sees.
     
     On untrusted XML this lets a remote, unauthenticated attacker force large heap
     allocations with a single start tag. With several `NsReader`s running
     concurrently on independent inputs (a common server pattern), the allocations
     stack and can exhaust process memory, causing the operating system to kill the
     process (OOM). This was confirmed against a real-world RPKI relying party (NLnet
     Labs Routinator), where concurrent RRDP validation workers parsing a crafted
     `snapshot.xml` exceeded the memory limit and the process was OOM-killed.
     
     ## Affected code paths
     
     Consumers using `NsReader` (which always calls `NamespaceResolver::push` before
     yielding `Start`/`Empty`), or calling `NamespaceResolver::push` directly. A plain
     `Reader` that does not perform namespace resolution is not affected.
     
     ## Remediation
     
     Upgrade to `quick-xml >= 0.41.0`. `NamespaceResolver::push` now rejects a start
     tag that declares more than `DEFAULT_MAX_DECLARATIONS_PER_ELEMENT` (256)
     namespace bindings, returning the new `NamespaceError::TooManyDeclarations`
     instead of allocating without limit. The limit is configurable via
     `NamespaceResolver::set_max_declarations_per_element` (use `usize::MAX` to
     restore the previous unbounded behavior), and `NsReader::resolver_mut()` is
     provided to reach it.
     
     There is no clean workaround for `NsReader` consumers before 0.41.0, as the
     allocation happens inside the reader with no configuration knob to cap it.
   ├ Announcement: https://github.com/tafia/quick-xml/issues/970
   ├ Solution: Upgrade to >=0.41.0 (try `cargo update -p quick-xml`)
   ├ quick-xml v0.37.5
     └── tools v38.0.0

error[unsound]: Rand is unsound with a custom logger using `rand::rng()`
   ┌─ /home/runner/work/libdatadog/libdatadog/Cargo.lock:75:1
   │
75 │ rand 0.8.5 registry+https://github.com/rust-lang/crates.io-index
   │ ━━━━━━━━━━━━━━━━━━━━━━━━━━━━━━━━━━━━━━━━━━━━━━━━━━━━━━━━━━━━━━━━ unsound advisory detected
   │
   ├ ID: RUSTSEC-2026-0097
   ├ Advisory: https://rustsec.org/advisories/RUSTSEC-2026-0097
   ├ It has been reported (by [@lopopolo](https://github.com/lopopolo)) that the `rand` library is [unsound](https://rust-lang.github.io/unsafe-code-guidelines/glossary.html#soundness-of-code--of-a-library) (i.e. that safe code using the public API can cause Undefined Behaviour) when all the following conditions are met:
     
     - The `log` and `thread_rng` features are enabled
     - A [custom logger](https://docs.rs/log/latest/log/#implementing-a-logger) is defined
     - The custom logger accesses `rand::rng()` (previously `rand::thread_rng()`) and calls any `TryRng` (previously `RngCore`) methods on `ThreadRng`
     - The `ThreadRng` (attempts to) reseed while called from the custom logger (this happens every 64 kB of generated data)
     - Trace-level logging is enabled or warn-level logging is enabled and the random source (the `getrandom` crate) is unable to provide a new seed
     
     `TryRng` (previously `RngCore`) methods for `ThreadRng` use `unsafe` code to cast `*mut BlockRng<ReseedingCore>` to `&mut BlockRng<ReseedingCore>`. When all the above conditions are met this results in an aliased mutable reference, violating the Stacked Borrows rules. Miri is able to detect this violation in sample code. Since construction of [aliased mutable references is Undefined Behaviour](https://doc.rust-lang.org/stable/nomicon/references.html), the behaviour of optimized builds is hard to predict.
   ├ Announcement: https://github.com/rust-random/rand/pull/1763
   ├ Solution: Upgrade to >=0.10.1 OR <0.10.0, >=0.9.3 OR <0.9.0, >=0.8.6 (try `cargo update -p rand`)
   ├ rand v0.8.5
     └── (dev) libdd-common v5.1.0
         └── tools v38.0.0

advisories FAILED, bans ok, sources ok

Updated: 2026-08-04 13:22:27 UTC | Commit: 4e8b29b | dependency-check job results